1. Field of the Invention
This invention relates to creating an interface between processes and more particularly relates to creating a hub server/application interface.
2. Description of the Related Art
A hub server is often used to provide computing resources to a plurality of enterprise applications including web-based applications. For example, a hub server may be employed to host a web-based order management application, a data base application, and the like. The computing resources may include database resources, data storage resources, processing resources, and the like.
The hub server may integrate one or more applications on a common platform or across disparate platforms. The integration of the applications may allow the applications to share data, enhancing the usefulness of all applications. In integrating the applications, the hub server may provide the computing resources for applications that are written specifically to interface with the hub server. For example, a transaction processing application may be written specifically to interface with a specified hub server. In addition, the hub server may provide computing resources for applications that are not written to interface with the hub server. For example, the hub server may provide computing resources to an inventory management system that was written for use with a stand-alone inventory database.
In one embodiment, the hub server organizes computing resources as objects. The objects are referred to herein as business objects. Business objects are objects specifically designed to satisfy needs of one or more business processes. Business objects may comprise transactions or events including one or more functions and employing elements in a data structure, elements of a database schema, or the like. For example, a business object may include a function to search a database column for a specified identifier, and a function to retrieve a data value from the row of the identifier.
The business objects of the hub server may be named and organized differently from analogous objects of the applications interfacing with the hub server. In addition, business objects may be generic and used to interface with a plurality of applications. For example, a transaction processing application, a financial application, and an inventory management application may each use a generic finished goods inventory business object. The generic finished goods inventory object may include functions that sum data values in a database column for each application.
The hub server may employ an adapter agent to interface with an application. Adapter agents provide prepackaged connectivity that integrates disparate industry-specific and cross-industry computing systems by pulling and uniting information from packaged and custom applications; mainframe systems; technology protocols; databases; and trading partners. The adapter agent may convert generic hub server business objects into specific objects employed by an application. Similarly, the adapter agent may convert a specific application object into a generic business object for use by the hub server. For example, the adapter agent may convert an application object that retrieves a finished goods inventory value into the generic finished goods business object described above.
The hub server may employ an object discover agent (“ODA”) to discover the objects associated with an application. In addition, the ODA may generate a generic business object that is equivalent to a discovered application data object. For example, the ODA may communicate with an application to discover the objects employed by the application. The ODA may further generate generic business objects, mapping hub server functions and data equivalent to the application objects. Thus, the ODA may create the business object/application object relationships that allow the adapter agent to interface between the hub server and the application.
Unfortunately, the ODA is typically written using a manual process. For example, a programmer may write the ODA source code, generate a run-time ODA, and test the ODA. Each of these operations traditionally takes place using separate and distinct tools and environments. While the programmer may refer to previously created ODA source code in writing new ODA source code, the programmer often omits code functions and parameters, fails to make important modifications, and may otherwise make mistakes developing the source code. Significant time and expense may be expended in discovering and correcting omissions and/or mistakes. Similarly, the adapter agent is also typically written using a manual process. And as with the ODA code, the programmer may also omit critical source code and otherwise make mistakes that increase the time and cost of creating the adapter agent.
From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method that facilitate and automate the creation of an interface between an application and a hub server, including the ODA and adapter agent. Beneficially, such an apparatus, system, and method would reduce the time and cost of creating an ODA and an adapter agent.